Centralize Swift checkout message ingress validation - #644

What changes are you making?

This PR centralizes Swift message admission behind an internal CheckoutMessageIngressPolicy.

Incoming WebKit messages now pass through an internal CheckoutMessageIngressPolicy before reaching the checkout protocol client:

let ingressPolicy = CheckoutMessageIngressPolicy(
    configuredOrigins: ShopifyCheckoutKit.configuration.allowedMessageOrigins,
    checkoutURL: loadedCheckoutURL
)

switch ingressPolicy.evaluate(message, in: self) {
case .accepted:
    break
case let .rejected(rejection):
    switch rejection.reason {
    case .childFrame:
        OSLogger.shared.debug("Ignoring checkout message from a child frame.")
    case .unsupportedPort, .originNotAllowed:
        OSLogger.shared.warn(
            "Rejected checkout message from \(rejection.origin): \(rejection.reason.logDescription)"
        )
    }
    return
}

// Only admitted messages continue into the existing checkout protocol handling.

The WebKit-specific overload adapts authenticated frame, origin, and request URL metadata into the policy's transport-neutral IncomingCheckoutMessage model. The core evaluator remains independently testable, while the WebView call site no longer assembles admission metadata itself.

The policy validates that metadata before a message reaches the checkout protocol client. Keeping this decision at the native WebView boundary means the protocol client can focus on handling admitted checkout protocol messages rather than transport trust.

Rejection behavior

A rejected message means that specific input was not trusted. It does not mean the checkout session failed: checkout may be displaying an external surface that also posts messages, and unrelated page activity must not be able to terminate an otherwise healthy checkout. The rejection branch selects the appropriate log level and returns before protocol processing begins.

• Child-frame messages remain debug-only because payment and 3DS iframes can produce routine bridge traffic.
• Origin and explicit-port-zero rejections are logged at warning level and dropped.
• Rejected messages never reach the checkout protocol client.
• Rejection does not transition PreloadState to .failed or evict the preload.
• Rejection does not create a CheckoutError or call .onFail / checkoutDidFail(error:).
• The rejection model remains internal because this approach does not expose a public diagnostics stream.

Consumer API

Consumers only configure the origins they trust. The existing lifecycle APIs remain reserved for actual checkout failures:

ShopifyCheckoutKit.configure {
  $0.allowedMessageOrigins = [
    "https://checkout.example.com",
    "https://*.example.com",
  ]
}

There is no message-rejection subscription. Rejections remain an internal signal that is logged at the appropriate level and dropped.

React Native consumer API

No React Native event or callback is added. Rejected native messages are logged and dropped; they do not dispatch onFail:

checkoutKit.present(checkoutUrl, {
  onFail(error) {
    // Called for checkout lifecycle failures, not rejected messages.
    reportCheckoutFailure(error);
  },
});

Before you merge